I'm trying to automate my TestFlight builds. It works great for the most part but when I include the changelog it claims that it "Successfully set the changelog for build" however I can't find the changelog text anywhere in AppStore Connect. It doesn't appear in TestFlight either.
Here's my lane:
platform :ios do
desc "Push a new dev build to TestFlight"
lane :dev do
increment_build_number(xcodeproj: "MyApp.xcodeproj")
build_app(workspace: "MyApp.xcworkspace", scheme: "devMyApp")
changelog = changelog_from_git_commits
add_git_tag
upload_to_testflight(
app_identifier: "com.myApp.dev",
changelog: changelog
)
end
end
When the lane gets executed I can see it successfully build, it pulls the git commit messages since the last tag, it uploads, waits for the app to appear, and it supposedly sets the changelog for the build. The changelog just doesn't appear anywhere.
Any ideas?
Related
We are using Github + CircleCI + Heroku with automatic deploys setup.
From time to time there are deploy errors that are not captured by CI (deployment fails event though CI run is fine). We have review apps set up for all our PRs.
It would be great if the PR would indicate this and stop us from merging if the deployment of the review app fails (that usually means the deployment of the staging/production app would also fail).
I could not find any documentation on this. The only possible way I see is to use the GitHub API to add a custom check for this.
Anyone solved this issue?
We have made a GitHub Action to test the deployment status of a Heroku Review App: https://github.com/marketplace/actions/heroku-review-app-deployment-status.
This can be used in the GitHub workflow to test the deployment status.
UPDATE: We wrote a nice blog post about different approaches to verify Review App deployment status.
Link: https://blog.niteo.co/staging-like-its-2020/
You can use Github's protected branches for this https://help.github.com/en/articles/enabling-required-status-checks
Navigate to your repository's settings -> Branches -> Add Protection Rule -> Select "Require Status Checks Before Merging" and select "CircleCI".
In order for this to work you need to cause CI to fail if your deployment fails. If you get a failure from Heroku, you should run any command that will return exit 1 as a status code, which will fail CI for you.
I have made my repo source a master branch and followed the instructions here: https://pages.github.com/, but I still cannot publish my site to Github pages (my index.html file is in the root). It says that "It is ready to be published", but I don't know how to actually publish it.
Github has had a major outage over the last 24 hours. It looks like they are still recovering and some actions are delayed.
We are working through the backlogs of webhook deliveries and Pages builds. We continue to monitor as the site recovers.
https://twitter.com/githubstatus/status/1054442347570839552
We have strict build expiration enabled on our pull requests in VSTS and block PRs from completing until a successful build has been achieved. This works well and keeps our master branch clean. However, a source of significant frustration that we regularly face is when we have multiple PRs queued and which ultimately expire due to a PR which is ahead in the queue being completed.
Consider the scenario:
Developer A creates a new PR (with auto-complete turned on) which queues a new build
Developer B creates a new PR before Developer A's PR build has completed which queues another build
Developer A's build passes, the PR auto-completes and the changes are merged into the master branch
Developer B's build starts, completes and passes
Developer B's build expires as the master branch has been updated since the build was queued
Developer B has to re-queue their build...
We face the above problem almost daily and usually have several PRs backed up in the build queue. Our PR build takes ~1 hour to complete as it conducts extensive deployment and testing of the system. This leads to many hours of wasted build server time and some very frustrated developers.
Does anyone know of a way to avoid the above happening. It seems that an option to automatically remerge a PR whenever the master branch is updated would fully solve this issue.
There isn’t the automated way to avoid that in VSTS, you can change the build policy to expire after XX hours.
Go to version control admin page
Select a repository=> A branch=>Branch Policies
Click Edit of a build definition in Build validation section
Select After hours if master has been updated option and specify the hour.
I have set up Jenkins and Github such that whenever I push a commit to an existing pull request, it automatically adds a comment and triggers a Jenkins build. Prior to today, Jenkins amended that comment with the status of the build and the functional tests executed. (So I know that part works.)
Today, I updated Jenkins and Jenkins ceases to notify Github of the build status. When I check the Jenkins configuration, the post-build section says:
Set build status on Github commit [deprecated]
This notifier will set GH commit status. This step is DEPRECATED and will be migrated to new step in one of the next major plugin releases. Please refer to new universal step.
Are they saying they removed functionality and I need to either downgrade or wait for them to restore it when they get around to releasing an update?
Alternatively, if they want me to start using this new "universal step", where can I find the documentation on setting that up?
I looked at Show current state of Jenkins build on GitHub repo but it appears the answers to that question are now obsolete (answered six months ago).
I am currently using Jenkins version 2.3, Github plugin 1.19.1 and Github API plugin 1.75.
I think you may have been bitten by this issue: https://wiki.jenkins-ci.org/display/JENKINS/Plugins+affected+by+fix+for+SECURITY-170
It says
If using the standard ${sha1} branch spec, builds will fail with "Couldn't find any revision to build".
Pull requests remain in the "pending" state as the plugin fails to update the PR with the build outcome
It sounds like this can be fixed by using a whitelist of terms. In my case, this was handled by another engineer, so I can't provide firsthand details.
I have a teamcity project running a build against github repo. On completion of the build, it uses a build feature of teamcity named "Report Change Status to Github" which reports the build status using - https://api.github.com
Now I would like to have another teamcity project run a build against the same github repo and report the build status to github.
How do I make github display the 2 status checks differently? Despite the 2 builds reporting status to github, github just displays "1 pending check" or "1 status check completed successfully"
Edit: I didn't realize you already have the plug in installed, but I am going to leave the steps for other users. I think you need separate build configurations and to make sure you customize the context setting.
I was playing with this today and you can't use JetBrains "Commit Status Reporter" to do this. You can use this plugin though: https://github.com/jonnyzzz/TeamCity.GitHub
It wasn't straightforward to install--
Go here (choose Log in as guest): https://teamcity.jetbrains.com/viewType.html?buildTypeId=bt398 and
Click the "View" link in the "Artifacts" column in the latest successful build.
Then you click teamcity.github.zip and it will download a zip file
Then you upload that zip to TeamCity in the plugins section
Once you do that, go to Build Features and click "Add Build Feature" and select "Report change status to GitHub".
Then fill the form out with something like this (Note: You will need this for each build configuration you want reported. I am also running each build on separate agents which might be necessary):
Statuses are created with something called a context:
https://developer.github.com/v3/repos/statuses/#create-a-status
For each commit, the latest status for each context is shown. And for the pull request overall (next to the merge button) the latest per-context statuses of the latest commit in the pull request are shown.
This means that if you want multiple status checks to show up -- those statuses need to be created with different contexts. And that's something defined by the application which is creating statuses, not GitHub. GitHub only displays the statuses.