I am looking for a way to view last accessed or the date of the latest activity log, commit, modify, etc. on a project using the CLI so I can get a rough idea of what projects are(n't) in use for an account cleanup.
Would anyone have a recommendation of how to do this programmatically, or how I can find similar data.
Related
We have a heroku review app pipeline configured with github integration.
Currently, every time after a new app is created, we have to go in and manually disable automatic deploys in the UI here:
I was looking around for one of the following options to remove this manual step:
call an api to disable auto-deploy on a review app
change a pipeline level setting that determines the default value of auto-deploy for new review apps that get created
but so far I haven't been able to find anything.
Any suggestions for how this might be achieved would be much appreciated.
I've installed the Google Cloud Build app from Github Marketplace, and enabled it on several repositories, only to discover that enabling access for those repositories automatically starts running the Google Cloud Build "check" after every PR or push to a PR. Since some of those repositories are not actually ready for Google Cloud build, I needed to turn off the checks... I used the URL mentioned in the docs to get to the page where you can select which repositories should be connected to your GCP project, and unchecked a bunch of them... this disconnected them from the project, but, surprisingly, did not disable the Github checks! So now, there are Github checks on several repositories that just result in an error because they're not connected to any projects in Cloud Build.
Surely, it is not an uncommon use case to need a way to "disable Checks" on a per-repository basis - is there any way to do that?
(If not, consider it a requested feature if there are any Google Engineers reading!) ;)
I did talk to chat support, and the only way we could figure out to remove the checks would be to uninstall Google Cloud Build completely from the entire organization, which I don't want to do because we do have some setup that I want to keep, and I don't know how much of that configuration would have to be redone if I uninstalled it completely.
Here is a screenshot of the broken check that I can't disable:
I think there are 2 steps to disable CloudBuild,
1. Disable on CloudBuild itself. For some time I kept seeing 2 builds per push made, but disabling a trigger on CloudBuild helped fix that.
2. On Github, you can configure the Cloudbuild app to monitor a specific repo on the organization level setting.
3. If you feel a lot adventurous though and it's not solved, on the project level setting, you could delete the Webhooks integration for cloudbuild, as that's what Github notifies of each build.
It can be found within GH App installations:
https://console.cloud.google.com/gcb-github-registration
Select the GH account used for your link between Cloud Build and GH, then the GCP project you want to edit.
Here connected repositories can be edited, and in the second step (Trigger settings), the "Default GitHub Checks" can be disabled.
You can also goto settings of your repository and click installations inside settings.
And then remove Google cloud build from Installed apps and authorized github apps.
Cloud Build Triggers are still in beta, and have gone through several updates since this question was posted, but it now appears that the "Github Default Checks" are no longer hidden from management. They are now explicitly offered (but not automatically created) when connecting a repo, and you can finally view and disable (or delete) individual "Github Default Checks" on the trigger management page: https://console.cloud.google.com/cloud-build/triggers
I'll leave this as unanswered, because I'm uncertain this is how it is working for everyone, or that this answer will remain true, but if it works for you, feel free to vote up the answer!
To link GCP Project to the Github repository, create a trigger by clicking on resolve link, besides Action Required and then disable the same. For me this procedure worked out.
Since today I have the problem that the CF push task in bamboo will hang on the Uploading app files step. I didn't change anything besides some environment variables and of course a bit of code. The log looks like this:
Creating/updating app App-X...
Uploading App-X... Uploading app files
from: /home/bamboo/bamboo-agent-home/xml-data/build-dir/App-X-JOB1/
This will run forever without the Application Cloud getting any updates.
Are there any good ways to debug CF push tasks?
You should try to debug your deployment as close as possible to the way you execute it on bamboo. If you do a cf push, the cf cli automatically tails the staging logs for you, so if you don't see any output during staging it's unlikely that cf logs will tell you anything more.
Since the last thing you're seeing from the log snippet posted above is an "uploading" statement, I would check these things:
use a more recent version of the cf cli, they recently added an upload progress bar which might be useful
check if you have either a .gitignore or .cfignore file in the dir you're pushing from so that you don't push any files you don't need (docs)
hanging pushes may be a plain malfunction of the CF platform you're using, e.g. due to inavailability of CFs internal blob store, no more cells available for staging etc., there's tons of possibilites here
Disclaimer: I'm a co-founder at Meshcloud and we provide public and private (also on-site/hybrid) managed Cloud Foundry hosting in the EU.
You can get the full trace log of a push by using cf push -v, which might give you a hint of where (and possibly why) it is stuck.
Other useful debugging tools are cf logs / cf logs --recent and cf events, but if the push itself simply hangs (rather than failing), they might not produce anything at all. Have you tried waiting for the timeout?
Also, please make sure you're using the latest cf cli version.
I am trying to see how the OpsHub migration tool works before I perform real migration.
And hence I am trying with a on premise TFS instance and a trial created Team Services (was Visual Studio Online) instance. but when I finish configuring the stuff and it start to validate all the settings put in, it is giving error for Team Services Project Collection URL. It is taking collection URL as
https://********.visualstudio.com/********
where as it should only use
https://********.visualstudio.com/
Not sure how to get over it and now fully stuck.
This is caused by the change in VSTS:
Collection in the domain
Your Team Services account URL just got 18 characters shorter. We’ve
removed “/DefaultCollection” from the path. While it’s small, but
welcome change. It’s the beginning of a larger journey to how we
structure accounts. Learn more here.
Note that existing accounts will still give out the longer URL for Git
Clones in the Code hub. This is because to use the new shorter URL in
VS, you will need to reconnect Team Explorer using the shorter URL.
Today you either need to use the long or the short URL for an account
in VS, you can’t intermingle. Once we have enough clients updated such
that they just work seamlessly with either type, we’ll change the
default Git Clone URL to the shorter one as well.
Last but not least, we have a set of Release Management improvements.
Please download the latest version of OpsHub Visual Studio Migration Utility and then try again.
A similar issue here: OPS Hub - unable to migrate project.
I am trying to build a Project Server workflow using SharePoint Designer 2013.
The workflow itself is working. It can create a task in the Project Server task list and approving it progresses the workflow.
However, if you click "Additional Workflow Data" the history is always empty. I have been able to create a custom event to log in the history via designer, but I am looking for the true history of the workflow. In 2010, the history would show it entering each stage and other logging data. My 2013 workflow history shows nothing.
I have verified the account has permissions to write to the list. I have checked the IIS logs to see the workflows are running. I have checked the project server permissions and groups for the workflow proxy account. I have ensured "Workflows can use app permissions" is activated for the PWA collection. I have also tried "Copy-SPActivitesToWorkflowService" cmd to see if it needed to installation needed to be repaired. I have restarted the workflows, republished, bounced the boxes, but still not workflow history!!
Does anyone know how to resolve this issue or have other suggestions on where to look?
You need to use an 'Action' within the Workflow called 'Log to History List' and enter what you want the log to say at the point where you have added the Action.
The sticking point comes from a differences in versions.
In Project Server 2010, the workflows showed default actions and processes. In 2013, you cannot see all the various behind-the-scenes actions.
Any actions which you want to be able to trace, for example, when the project entered the stage, must be added into the custom workflow manually.