Question
Is there any way to point existing Amplify apps to new repositories? Failing that, is there a way to clone Amplify app settings (including Backend environments) from one app to another?
Background
I was a complete newcomer to AWS until several months ago, when I inherited responsibility for an existing set of AWS apps developed by another team.
In our AWS account, Amplify is configured to use GitLab repositories which were under the previous team's control. I got a copy of the code, but I don't have access to the repositories.
So I uploaded the code to a new Bitbucket repository, and now I need to point the existing apps in Amplify to the new repositories. My goal is to be able to push changes to my new repository and have Amplify detect those changes so the new build can be pushed.
3 Unsuccessful Solutions
I've tried approaching this problem from a few different angles.
1. Create a new app
I created a new app which points to the new repository, which proved to be very simple. But I didn't anticipate how difficult it would be to migrate settings (especially the Backend environment) from one app to the other. So I thought it might be simpler to point the existing apps at the new repository.
2. Reconnect Repository
I thought that configuring a new repository for an existing app would be relatively straightforward. Here's the procedure I followed.
Log into AWS Console and navigate to the Amplify service
From the list of apps, select the one I want to modify
Under "App settings", select the "General" tab
Click the "Reconnect repository" button
A dialog box popped up: "Reconnect your Git repository". It prompted me to select from a dropdown list of "Recently updated repositories", but that list was empty. There's no place to enter an address for a new repository, so this path seems to be a dead end.
3. Create a Connection
I tried to "Create a connection to Bitbucket" as described in AWS documentation here: https://docs.aws.amazon.com/dtconsole/latest/userguide/connections-create-bitbucket.html
But the "Developer Tools" console seems unrelated to Amplify. The connection was created successfully, but it doesn't appear in the "Recently updated repositories" list, and I don't know how else it can be used.
If you are okay with a CLI solution, have a look at the comment below from https://github.com/aws-amplify/amplify-hosting/issues/288#issuecomment-737192995
aws amplify update-app --app-id AMPLIFY_APP_ID --repository REPOSITORY_URL --access-token ACCESS_TOKEN
... worked for me, transferring from one github account to another
github account and repo. I know it's not quite what the OP was doing,
but thought it may be worth noting that:
The AMPLIFY_APP_ID is the last bit of the app ARN (e.g.
dXXXXXXXXXXXXX)
For github repositories, the access token is a
Personal Access Token (https://github.com/settings/tokens).
I gave it all of the repo and admin:repo_hook privileges. That had to be created from the repository owner's account, not a contributor.
This helped me to change that app to point to a different GitHub repository.
AWS CLI requires some setup though, the documentation is available here https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html
Edit: You might also have to Reconnect The Repository using the UI after changing it using the CLI
Related
I'm working with WSO2 Identity Server and I'm curious if there is a way to run the product in developer mode without building each component of identity server. I found a way to start the "My Account" component in dev mode by following this tutorial ( https://is.docs.wso2.com/en/5.11.0/develop/setting-up-my-account-in-a-dev-environment/ )
but I want to be able to modify different components such as recovery-portal and authentication-portal by forking and cloning the required github repositories and starting the entire app in developer mode in order to see the code changes in real-time.
AFAIK the developer mode will work only for the MyAccount and Console. You can refer to the doc for more details on that.
The recovery portal, the authentication portal etc. cannot be tried with the developer mode. However, there are two ways that you can try this.
Build the war files manually and add them to the WebApps directory. If the server is running, war file changes will automatically get deployed. If the server is not running, you have to delete the existing directory and restart the server.
You can do the changes to the JSPs that are deployed inside the pack. Once the changes are done, you can save the changes and the changes will automatically get deployed.
I use Java APIs for the CRUD operations of the google cloud deployment manager API. I can create, preview, delete deployments OK.
But when I try to update an existing deployment that's in preview mode, the API returns the below error.
Deployment in preview must not have a target with UPDATE
The same inputs works OK for create and preview. So, I'm sure that the inputs are OK.
I looked up for others who have reported this issue.
Here is one such report but no solution.
Does anyone know if there's a git hub repo for google cloud deployment manager where we can report this issue?
As mentioned in the answer here, is a known issue and you can still use the workaround suggested.
I have created an issue tracker for this error message. So, you can add your comments there and follow up for upcoming updates.
I am currently fiddling around with AWS CodePipeline for the first time and set up the Source and the Build step so far with a demo project.
I have connected the Source Step with a GitHub account (a system-account we use), with admin access to all Repos. As the documentation states, the OAuth-scopes admin:repo_hook and repo are required for this to use; which are granted and the connection is fine.
As the title of this question already states: The integration works just fine - when I push a new commit on master to GitHub, the Pipeline starts working and runs through smoothly.
My question however is: How? As the docs state here:
To integrate with GitHub, AWS CodePipeline uses OAuth tokens
however, when looking in my GitHub settings, I would have expected to find the application listed as an "OAuth application" directly on the Repository or on the organization "OAuth applications", but neither is the case!
Thus, I am wondering how CodePipeline recognizes my new commit. Is it polling the SCM or some other sort of magic? I did not find any WebHooks either.
Thank you in advance!
AWS CodePipeline is connected to GitHub via the new "Integrations" concept: https://github.com/integrations/aws-codepipeline
This concept was announced here: https://developer.github.com/changes/2016-09-14-Integrations-Early-Access/
GitHub Integrations authenticate using JSON Web Tokens and private/public keys, so I'm not sure if AWS are technically correct in describing that as "OAuth" or not. Details here: https://developer.github.com/early-access/integrations/authentication/#as-an-integration
We are using Gitlab (7.10.2) and Redmine (3.0.2).
All issues are managed in Redmine and Gitlab manages all git-repositories.
We set up Gitlab via the UI so far that commits with the message 'Close #234' are clickable and pointing to the corresponding Redmine ticket website.
We now want to achieve that tickets in Redmine are directly linked with Gitlab commits.
If we are using the internal Gitlab issue system and set the commit-message to ‘Close #234’ the ticket 234 is automatic closed and linked with the commit.
But with Redmine as issue service system we are not able to automatic close issues with commits or have any information about this in Redmine.
Does anyone knows how we can modify Gitlab and/or Redmine to close Redmine tickets with Gitlab commits?
You can use Redmine as an issue tracker with setting the redmine service in Gitlab (In your project -> Services -> Redmine -> fill the URLs, and set active). If this works, when you press "new issue" button in Gitlab, you are redirected to Redmine new issue page. In Gitlab you should have WebHook to inform the Redmine about new push into the repo. This can be set in the settings "In your project -> Settings -> Web hooks" (how, see here).
In Redmine go to Administration -> Settings -> Repositories. Check your referencing keywords. "closes" or "close" should be in the list. Finally in the same tab there is the table at the bottom, where you choose tracker, your fixing keyword (closes, close), set applied status to "Closed", and choose the appropriate amount of % Done (100%).
Similarly you can set other keywords to change status in Redmine tickets.
Use the redmine_gitlab_hook to keep Redmine repo up-to date.
I'm just getting started with Jenkins CI, and had a question which I'm
struggling to find answers for in the docs or online. Wonder if
someone might be able to offer some advice?
I'm attempting to use it to automatically deploy my dev and stage
branches of my Django projects which are hosted on a Github
organisation repository (ie, private). At the moment I have a user
"django" who can access the Github repo via a Github deploy key. My
Jenkins user can't access the repo. What's the best practice way of
dealing with this - should I be creating an ssh deploy key for the
"jenkins" user, or should I be getting Jenkins to run as my "django"
user? I've seen mention if a HUDSON_USER in a newsgroup post, but I
can't find reference to this in the docs.
Many thanks!
Ludo.
I have not worked with Github and so this answer may not apply at all, but we do use Jenkins and we use both CVS & Subversion for source control.
In our system, we use different username/password combinations for all three (Jenkins, CVS, Subversion), and it has had no adverse effects yet (it has been a year since we deployed Hudson - currently building 50+ projects).
As long as you can get Jenkins to access the repo using your github deploy key, you shouldn't have to change Jenkins to run as django, or create a jenkins user key for github. Personally, I would keep them separate.
Did you try this?
Contact your OS admin team to grant to access to perform few operations on your version control using SUDO access.
OR
run the command using
sudo -H -u <username> command parameters..